This invention relates to integrated circuits and, more particularly, to functional testing and debugging of integrated circuit designs.
Some present day designs of integrated circuits (ICs) comprise a plurality of module, or core, designs (and associated design layouts) that are interconnected within the integrated circuit to create a whole. Such ICs are sometimes referred to as “systems on a chip” (SoCs). The designed SoCs may include core designs that the party designing the integrated circuit has created before, core designs purchased from another party, and core designs that are created specifically for the designed SoC; sometimes is referred to as user defined logic (UDL) block. In connection with the previously created designs, it is recognized that there may exist outputs and/or inputs that are not needed for the specific SoC design undertaken, and those effectively constitute points of access of the core—in addition to the functionally employed inputs and outputs—that may be used for testing the core as well as the entirety of the SoC design.
The aforementioned Ser. No. 10/425,101 patent application discloses a beneficial design approach for SoCs, where each core is encompassed with a wrapper that includes a functionally reconfigurable module (FRM). A wrapper is a collection of elements, including circuit interface elements between essentially every input terminal of the core and circuitry outside the core, and between essentially every output terminal of the core and circuitry outside the core. The FRM can be configurably connected to any of the circuit interfaces, and can also be configured to realize any function. Spare leads are additionally included to permit connectivity from the FRM directly (i.e., not through the circuit interface elements) to circuitry outside the wrapper. The circuitry outside the core can be another wrapper, a UDL block, inputs of the IC, or outputs of the IC.
FIG. 1 depicts an arrangement in accord with the disclosure presented in the aforementioned patent application where an SoC includes core 10 that is wrapped by wrapper 11, core 20 that is wrapped by wrapper 21, and core 30 (a UDL block) that is wrapped by wrapper 31. Illustratively, core 10 has three inputs and four outputs (12, 13, 14, and 15). Core 20 has four inputs, three outputs (22, 23, and 24), and UDL 30 has three inputs and two outputs (32, and 33) that are connected to the SoC output terminals of the IC. The blocks labeled “I” are the aforementioned circuit interface elements.
Each interface element that provides a signal to a core is adapted to configurably provide either an incoming signal (the signal shown in the FIG.) or a signal provided by the associated FRM (not shown in the FIG.). Similarly, each interface element that outputs a signal from a wrapper is adapted to configurably provide either an output of the core (the signal shown in the FIG.) or a signal provided by the associated FRM (not shown in the FIG.).
In is noted that in the illustrative SoC of FIG. 1, core 20 has one output (25) that is available but is not needed for the FIG. 1 SoC design. This intends to illustrate the above-mentioned notion that an obtained core layout that had been previously designed might have inputs and/or outputs that were needed for the application for which the core was designed but in the FIG. 1 application those might not be needed.
In addition to the necessary signal connections between wrappers 11 and 21, and between wrappers 21 and 31, including spare leads, the FIG. 1 SoC includes manager circuit 40 through which control is exercised over the SoC. It accepts a test clock, a control signal, and information through a serial Scan-in input. It receives Scan-out (SO) information (serially) from the SoC via lead 42 and is adapted to output that information, as directed by control 40, on the lead SCAN OUT. In turn, subject to desired processing within manager 40, the manager applies the test clock signal to each of the wrappers, Not shown in FIG. is a clock distribution system that allows the test clock to replace the functional system clock(s). The manager 40 could be compatible with, for example, the JTAG controller specified in the “Standard Test Access Port and Boundary-Scan Architecture,” IEEE Standard P1149.1, 1990.
In addition, the serial SI input of manger 40 is applied to wrapper 11. The SO output of wrapper 11 is connected to the SI input of wrapper 21. The SO output of wrapper 21 is connected to the SI input of wrapper 31, and the SO output of wrapper 31—which is the Scan-out signal of the FIG. 1 SoC—is connected to the manager 40. These connections establish a serial communication mechanism among the wrappers and the manager 40, which can be used to configure the FRMs or to send data to, and receive data from, the circuits configured in the wrappers. This communication mechanism could be compatible, for example, with the mechanism described in “Standard for Embedded Core Test” IEEE Standard P1500, 2003. Alternative communication means, such as a special-purpose debug bus, are also possible, and their nature is not essential for the disclosed innovation.
A useful technique for checking the design of integrated circuits (ICs) is called assertion checking. In assertion checking, a collection of conditions is identified that are expected to hold true at any time during the operation of a properly working SoC. The model of the SoC being tested can thus be simulated by application of various input test vectors, and its signals are checked against the collection of assertions. The signals checked by an assertion may include any internal signal. When an assertion “fires,” indicating that the asserted condition that should be met is not met, simulation can stop and the party performing the testing can attempt to analyze the reason for the assertion's failure.
While assertion checking in simulation is a widely used technique, and a simulation run may use hundreds of assertions, employing assertions for debugging hardware is much more constrained.
In general, any assertion can be implemented in hardware, e.g., within the manufactured SoC, but this is a costly approach because it permanently reduces the amount of “real estate” that is available for the normal operation of the SoC. Moreover, in addition to the effective cost associated with appropriated chip “real estate” to implementing hundreds of assertions in the SoC, this solution is not flexible, since the functional problems occurring in silicon often require the implementation of new assertions.
A more economical solution involves using additional hardware to observe many internal signals, run-time programmable logic to select a subset of these, and a run-time programmable assertion logic checking the selected subset of signals, and a clock-control logic to stop the operation of the SoC when an assertion fires. Such a system is illustrated in the paper “Silicon Debug: Scan Chains Alone Are Not Enough” by Gert Jan van Rootselaar and Bart Vermeulen, published in the Proc. International Test Conf., 1999. However, this solution does not provide the desired flexibility, since new signals and new conditions to be checked cannot be added at run-time. As an aside, in this paper the assertions are referred to as “breakpoints.” The described system is an example of at-speed debug, where the tested SoC is exercised in its normal operational mode, with a clock that is at the normal operational speed. The clock is not stopped while the assertions are checked, unless an assertion fires, i.e., fails.
An SoC may have several clock domains, each one having a different system clock signal. Firing of an assertion may stop one or all the functional clocks. In the following, clock stopping may refer to either case.
Usually all the functional registers of an SoC are setup so they can work as scan chains in test mode. Typically, a scan chain has a serial input (SI), a serial output (SO), and a scan-enable control input (SE). When SE is asserted, the register operates as a scan chain, otherwise data are loaded in parallel. (Other scan design techniques exists, but their operation is similar.) SE is typically shared between all registers in the same clock domain. For manufacturing test, the scan chains are separately operated to scan in test data and to scan out the captured data. The same scan chains are also used for debug—when the functional clock has been stopped as a result of an assertion firing (or for any other reason), the internal state of the hardware can be examined (manually or by software) by scanning out all the scan chains. For this operation the test clock shown in FIG. 1 as TEST CLK replaces the system clock, and all the scan chains are connected together in a single chain, connected to the pins SCAN IN and SCAN OUT of the test controller 40 of FIG. 1. Scanning back in the scanned-out state allows restoring the state to restart the normal operation from the last state; the scan-out and the scan-in operations may proceed concurrently by connecting the scan-out pin back to the scan-in pin to achieve a circular scan. If desired, the scanned-out state can be modified before the scan-in, so that the normal operation will restart from a different state. This mode of debug is called single-step debug.
Single-step debug is typically done manually under user control only at several points during the test, because performing scan-out and scan-in operation after every test vector would require too much time. To illustrate, if the test has 100,000 vectors, and the SoC has 500,000 flip-flops, and the test clock runs at 10 MHz, doing a full-scan dump at every cycle would make the entire test run in about two hours. Hence with the current state of the art, one cannot check assertions involving flip-flops on scan-chains, unless these flip-flops are made directly observable (allowing checking through at-speed assertion checking).